Throughout this disclosure including in the claims, the expression “system” is used in a broad sense to denote a device, system, or subsystem. For example, a device that implements a clock may be referred to herein as a system, and a system including such device may also be referred to herein as a system.
Throughout this disclosure including in the claims, the expression “secure clock” denotes a clock (or a system implementing a clock), where the clock is configured to be set to a reference time (e.g., an initial time set at time of manufacture) and to be adjustable relative to the reference time subject to predetermined constraints. Typically, a secure clock is initially set by a user or trusted time authority and once initially set, it is “locked” such that restrictions are imposed on further adjustments. For example, a secure clock may be configured to respond to a request to adjust its time by determining if the requested adjustment time (summed with all previous adjustment times since the initial setting, if any) is within a predetermined maximum adjustment limit (a maximum cumulative adjustment time relative to the reference time), and performing the requested adjustment only upon determining that the requested adjustment time (summed with each prior adjustment time) is within the maximum adjustment limit.
In some cases, the adjustment limit is (or is a function of) a predicted range of clock drift or some multiple of a predicted range of clock drift. The predicted range of clock drift may be determined in any suitable way. For example, the predicted range of drift may be the worst-case drift of the clock as determined from tolerances of the components used in the clock, preferably taking into account the operating and storage temperature ranges with and without power applied to non-clock portion of the device or other system with which the clock is associated (assuming that power is continuously applied to the clock, whether or not the associated system device is powered and operating). A typical tolerance may be in the range of 10-50 ppm.
Many devices (e.g., digital content reproduction devices) and other systems implement time-based access rules (e.g., Digital Rights Management or “DRM” rules) that require a clock to indicate times with respect to which rights are validated. For example, playback of audio or video content may be permitted only during a predetermined time interval (e.g., only during an X-hour period commencing at a reference time, which may be a specific UTC time or other universal time). The clock, which may be implemented internally or may be an external clock that is accessed from an external source, typically must be accurate (so that permissions are granted only when they should be) and typically must be a secure clock (so that a user cannot easily defeat the DRM by setting the current time to a false time within a permitted time window).
A variety of systems and methods are currently used for maintaining both accuracy and security of a secure clock. Some systems lock an internal clock to an external secure clock so that the internal clock does not drift. For example, a clock in a processing system may lock to a Network Time Protocol (NTP) server via the Internet using secure network transactions, or a clock in a Global Positioning Satellite (GPS) receiver may lock to a clock provided by the GPS system.
However, in some circumstances either no connection to a secure external clock is feasible or a continuous connection to a secure external clock is unavailable. If no suitable secure external clock is available, a free-running internal clock can be used as a secure clock. However, a free-running clock suffers from drift and will typically need to be adjusted from time to time in order to maintain accuracy while preserving security (e.g., so as to prevent users from easily defeating DRM restrictions by setting the current time to a false time within a permitted time window).
U.S. Pat. No. 7,266,714, issued Sep. 4, 2007 (assigned to the assignee of the present invention), discloses a method for adjusting the time of a secure clock only upon determining that the degree of adjustment is within a limit based on the clock's initial time. U.S. Pat. No. 7,266,714 teaches adjusting a free-running secure clock in response to an adjustment request only if the requested adjustment (cumulated with previous adjustments to the clock) would not exceed a predetermined limit (a predicted clock drift). The clock may be initially set by a user or trusted time authority or the like. The method includes the steps of receiving a request to adjust the clock, determining if the requested adjustment (summed with prior adjustments, if any) is within the limit, and permitting the request only if the degree of requested adjustment summed with any prior adjustments is within the limit, or performing a partial adjustment in response to the request (to adjust the clock as nearly as possible to the requested adjusted time without exceeding the limit). U.S. Pat. No. 7,266,714 also teaches synchronizing each of at least two secure clocks (in a set of secure clocks) sequentially to one of the clocks in the set (e.g., to a “newest” clock in the set which has been most recently updated using an external clock).
In many applications, multiple free-running secure clocks are needed. For example, in a multiplex motion picture theater each of two or more content playback devices or other systems may implement an internal secure clock. All the secure clocks may need to be adjusted for accuracy and synchronized subject to at least one predetermined adjustment constraint. All the secure clocks may be subject to a common adjustment constraint (or set of adjustment constraints) or each may be subject to a different adjustment constraint or set of constraints.
An exemplary system that uses multiple secure clocks is a D-Cinema multiplex installation satisfying the well-known Digital Cinema System Specification, Version 1.2, promulgated by Digital Cinema Initiatives LLC. Multiple IMBs (Image Media Blocks) are present in such an installation, and each IMB implements its own secure clock known as a Secure Real Time Clock (“SRTC”). Under normal circumstances, the SRTCs are adjusted and synchronized by setting them periodically using an external secure clock (an NTP server) or a clock derived from an external secure clock. Each SRTC has its own predetermined adjustment limit (a maximum allowable adjustment relative to an initial time that is set at manufacture) determined from a predicted range of clock drift. However, the secure SRTCs in IMBs (“IMB clocks”) are typically of relatively low quality and subject to wide swings in temperature. This can result in large amounts of drift for each IMB clock and thus large (e.g., up to 5 minutes per year) time differences between the IMB clocks due to drift after the IMB clocks have been set to a common initial time (e.g., by being synchronized to an external clock). There is a need for adjusting (to satisfy applicable accuracy requirements subject to security constraints) and synchronizing a set of IMB clocks in a common installation without using a clock external to the IMB clocks. This is because royalties, licenses, and/or other events and quantities may be timed off one or more IMB clocks and it is often not feasible to synchronize each relevant IMB clock using an external clock sufficiently frequently to satisfy applicable accuracy requirements.
More generally, there is a need for a method for maintaining synchronization and accuracy of multiple secure clocks that are free running, but configured to be adjusted by a user to correct for drift, without compromising the security of each such clock and without using an external clock. The expedient of synchronizing each secure clock in a set of free running, secure clocks from time to time (e.g., periodically), each time by choosing one of the clocks in the set and synchronizing each of the other clocks sequentially to the chosen clock, typically will not provide sufficient accuracy because the chosen clock may be subject to significant drift.